home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re ODF Container < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF Container
  2. Sent:        5/28/96 9:06 PM
  3. Received:    5/29/96 8:36 AM
  4. From:        Jim Lloyd, jim@melongem.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Doyle, you might also want to check out the "Merged Part Suites" note in
  9. the Development Notes folder.
  10.  
  11. Jim Lloyd
  12.  
  13. At 2:56 PM 5/28/96, Henri Lamiraux wrote:
  14. >Just one random comment.
  15. >
  16. >Don't forget that moving C++ code into a shared library means that all
  17. >clients of this shared library have to use the same version of the same
  18. >compiler. This is why we don't have the framework layer of ODF in a
  19. >shared library. Until we can move the whole framework to SOM using a
  20. >direct-to-SOM compiler this in not doable for us. We would have to ship
  21. >one shared library for every C++ compiler and even one for each version
  22. >of a given compiler. On the other hand it is totally doable for you to do
  23. >it if you decide to use only one compiler and you don't expect any client
  24. >other than yourself using your shared library. But, the best solution for
  25. >object oriented code in a shared library is to use SOM not C++. If you
  26. >look at the ODFLibrary it is only exporting C and SOM classes.
  27. >
  28. >>    I was very happy to discover that ODF R1 has a container part editor. I
  29. >>was about to try to create something with its basic functionality, but you
  30. >>have saved me, and many others, the trouble.
  31. >>
  32. >>   There is one aspect of ODFContainer, however, that bothers me. I am
  33. >>attempting to convert a simulation into OpenDoc parts. The initial version
  34. >>should have about a dozen parts that function quite closely to what is
  35. >>already in ODFContainer. The problem is that each one of these parts will
  36. >>end have a lot of code that is almost identical. As far as I can determine,
  37. >>most of what is being done in the container framework classes is generic
  38. >>and could be put into base classes. In fact, only the Part, Frame, and View
  39. >>classes seem to contain features that require parts of them to be varied
  40. >>from part to part.
  41. >>
  42. >>    What I would like to have is a basic container framework that has most
  43. >>of its functionality in a shareable library, such as ODFLibrary. As in all
  44. >>good object oriented code designs, only the minimum amount of nonredunant
  45. >>code would have to be incorporated into each individual part. Since most of
  46. >>the new parts that will be produced in the future as likely to be based on
  47. >>ODFContainer, I would like to think that there is some way of reducing the
  48. >>their size by putting the redundant code in a common library. This approach
  49. >>would have the added bonus that most new users wil have a much easier time
  50. >>trying to understand ODF if most of the remaining complexity can be hidden.
  51. >>I would anticipate that new users will be able to create new parts in a
  52. >>fraction of the time that it is now requires since they need only
  53. >>concentrate on the portions that absolutely have to be modified. What would
  54. >>also be nice, is a set of tutorials derived from this simple container
  55. >>model.
  56. >>
  57. >>    I have made two different attempts to create such a container
  58. >>framework, but both ended up crashing when I tried to use them. My question
  59. >>is, then, whether this approach is viable at all. If someone with more ODF
  60. >>experience can help me, please let me know.
  61. >>
  62. >>Doyle Rhynard
  63. >>
  64. >
  65. >
  66. >.......................................................................
  67. > Henri Lamiraux                                      lamiraux@apple.com
  68. > Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  69. >.......................................................................
  70.  
  71.